Inefficient circular buffer implementation causes unnecessary allocations

This pattern allocates a new backing array and copies 64 elements on every append once the buffer is full. This creates GC pressure during rapid event streams and is inefficient.

Suggested fix: Use simple slice reslicing:

if len(a.activities) > maxActivityEntries {
    a.activities = a.activities[len(a.activities)-maxActivityEntries:]
}

Or for a more robust solution, consider implementing a proper ring buffer with fixed-size array and head/tail indices.

Removed rebuildTranscript() may cause stale display

The original code called rebuildTranscript() after runtime closure, but this was removed. If there are pending changes to activeMessages not yet reflected in the viewport, the user might see stale content.

Suggested fix: Verify that all message updates set transcriptDirty = true before runtime closure, or restore a conditional rebuild here.

Layout recomputed on every mouse event

The transcriptBounds() method calls computeLayout() and renderHeader() on every mouse wheel event. During rapid scrolling, this adds unnecessary CPU overhead.

Suggested fix: Cache layout bounds after resize events and reuse them:

// In App struct
type App struct {
    // ...
    cachedTranscriptBounds struct {
        x, y, width, height int
        valid               bool
    }
}

// Invalidate on resize
func (a *App) resizeComponents() {
    a.cachedTranscriptBounds.valid = false
    // existing logic...
}

Return value behavior undocumented

The handleRuntimeEvent function now returns a bool indicating whether the transcript needs to be rebuilt. This is a significant behavioral change that should be documented.

Suggested fix: Add function comment:

// handleRuntimeEvent processes runtime events and returns true if the 
// transcript needs to be rebuilt (i.e., when new messages are appended 
// to activeMessages).
func (a *App) handleRuntimeEvent(event runtime.Event) (transcriptDirty bool) {

Missing documentation for magic numbers

These constants lack comments explaining their purpose and rationale.

Suggested fix:

// activityPreviewEntries is the number of recent activity entries shown in the preview panel
activityPreviewEntries = 3
// maxActivityEntries is the maximum number of activity entries retained in memory to prevent unbounded growth
maxActivityEntries     = 64

Magic number for fixed height

The function returns hardcoded 6 without explanation. This could cause layout issues if activityPreviewEntries changes.

Suggested fix: Add comment explaining the calculation:

// activityPreviewHeight returns the height of the activity preview panel.
// Returns 6 when activities exist (2 for header/border + 3 entry lines + 1 padding), 0 otherwise.
func (a App) activityPreviewHeight() int {

Tool result message created without Name field

When appending tool results to activeMessages, the message is created without preserving the tool name. The payload.Name is only logged in the activity.

Suggested fix: Consider whether the Name field should be preserved for transcript rendering consistency. Review if renderMessageBlock expects tool name information.

Missing string length limits and function documentation

The title and detail parameters are stored without length validation. While maxActivityEntries limits entry count, each entry's strings are unbounded. A malicious or misbehaving provider could send extremely long payloads causing excessive memory consumption.

Suggested fixes:

1. Add length limits:

const maxTitleLen = 256
const maxDetailLen = 1024

title = strings.TrimSpace(title)
detail = strings.TrimSpace(detail)
if len(title) > maxTitleLen {
    title = title[:maxTitleLen-3] + "..."
}
if len(detail) > maxDetailLen {
    detail = detail[:maxDetailLen-3] + "..."
}

2. Add function documentation:

// appendActivity adds an execution event to the activity log.
// kind categorizes the event (tool, command, provider, etc.),
// title is the main display text, detail provides additional context,
// and isError marks error states. Empty entries are ignored.
func (a *App) appendActivity(kind string, title string, detail string, isError bool) {

Unreachable focus state for panelActivity

The focusLabel() method handles panelActivity, but focusNext() and focusPrev() in update.go only cycle through [panelSessions, panelTranscript, panelInput]. The Activity panel cannot be focused via keyboard navigation.

Suggested fix: Either add panelActivity to the focus order array, or remove this case from focusLabel() if it's intentionally unfocusable.